In the last lesson, we learned how to use the epoxy modules for simple communication between the main
and renderer processes in most cases.
This will be used to interact with one of the main process modules from the renderer.
For example, a user might click a button, which requires a dialogue to be displayed, in which case
the Renderer process can use the epoxy renderer module to message the main process and inform it that
a dialogue needs creating the dialogue module only being available in the main process, of course.
But instead of creating multiple channels for sending and receiving such messages, Electron does provide
a module in the renderer to make this more convenient.
The remote module remote is a collection of IPSI convenience methods that mimics the main process modules
allowing us to access them directly from a renderer process.
Kind of remote does have a few drawbacks, though.
For one, it's always risky.
Exposing the main process, which is running in a notorious environment to users so remote does pose
a significant security threat.
And if security is a concern for your application, then simply avoid the remote module.
And secondly, the remote module comes with a significant performance penalty.
Nothing noticeable on a per method basis.
But it's not something you'll want to use successfully in a loop.
For example, for those reasons, then electron actually disables the remote module by default, meaning
should we choose to use it?
Step one is going to be enabling it on a Web browsers web content, much like node integration in this
same web content object being for the main window set enable remote module through this now, allowing
us to require the remote module in this renderer process over to render a doges, which is of course
included in this indexed on XML file.
We are loading into the main window require, as with any other renderer module, using the structured
assignment remote.
From electron.
And I'll just lock that out for now.
We see the module object, which contains a few methods, and then most importantly, getas for almost
every main process module, so not the modules themselves, but essentially getters that use epoxy to
get a reference to a required module from the main process.
An important concept to understand, as this means those references to the main process modules won't
get garbage collected until they are destroyed in the renderer process as well.
The documentation for the remote module explains this in detail.
Yeah, lifetime of remote objects worth a read if you do decide to make use of this module.
So with that all said and the module enabled, let's see a simple example.
Let's say we want to create a dialogue from the main window as before.
We first need to require the dialogue module.
But instead of requiring it directly from electron, we now simply require it from the remote module.
So still using the structured assignment, say, CONSED dialogue from remote, same as writing remote
dialogue.
Then in a time out, just to make this a bit more graceful, say after two seconds call dialogue Duchow
message box.
I leave the browser window argument out so defaulting to the focused window, setting this dialogue
message property to dialogue from renderer.
And some buttons.
One and two, this returns a promise, so resolve it directly on this function within passing a callback
in which we can read the user selection are logged that out.
Save this.
We get the dialogue after two seconds, so click one of the buttons and in the browser Windows Dev tools,
the dialogue response object is locked out.
So very straightforward, everything still exists in the main process.
But using the remote module, we're seamlessly communicating via the renderer, allowing us not only
to invoke the method from the renderer, but also receive the response.
This then applies to pretty much all of the main process modules.
For example, in an earlier lesson, we saw how to create new browser windows using the window open
method and then reference them via a browser window proxy object.
But let's say for whatever reason, you need to create and have access to a new browser window instance
or render a process in its entirety, not just a proxy window.
Remote will allow us to do just that.
I'll require the browser window module again from remote.
Comment about this dialogue and again, in the exact same way we do in the main process, create a new
browser window instance, assigning to win a new browser window with an X coordinate of 50 Y or 50.
Three hundred white and a height of 250.
I loathe the same content as this main window window download file.
Index Dot GML.
Save this still in that time out, so two seconds after launching, we get the new browser window,
keeping in mind that just like this main window, this still exists in the main process.
Mind window now simply has a reference to it again, all via IPSI.
So that's the basics of using main process modules.
But these references also get extended beyond just accessing modules for use.
Remote will also allow us to get and use the main app reference from the main process, for example,
leaving this as is so creating the new window after two seconds.
Let's add another time out again after two seconds of this one firing in which we can access the main
app instance directly from the main process as remote DOT app.
Or we could have also assigned it to its own local variable, like these module references calling on
that app instant quit all reformats slightly.
They better get a reference to the app instance from the main process and Colquitt on it after two seconds
safe and check this.
The window gets created and another two seconds later, the entire app is quiet, all directly from
within the Renderer process.
If we take a look at the rest of the remote modules documentation, getting to what methods it provides,
we see first the require method that's just being the same as calling nodes native require in the main
process and right at the bottom here, a few more.
So really not that many methods at all.
We can read the main note processes, process, object, get a global variable from the main process,
or retrieve a reference to the browser window or web contents in which the module is being used.
Let's see a quick example of this.
Our comment about all of the new browser window code leaving the initial two second time out in which
we can get a reference to the main window being the renderer running this very script with remote dot,
get current window and assign this browser window reference to a variable main window, as it's called
in the main process calling main window dot maximize.
The app relaunches and two seconds later gets maximized, so overall, a very convenient module, just
be sure it fits the security requirements for your specific app.
And remember not to work with references in long running loops or you might start seeing some slowdown
in the next place, will see an alternative way of using epoxy to handle logic between processors.